x86 shadow: Update cr3 in PAE mode when guest walk succeed but shadow walk fails

When running in PAE mode, Windows 7 (apparently) will occasionally
switch cr3 with one of the L3 entries invalid, make it valid, and then
expect the hardware to load the new value.  (This behavior is
explicitly not promised in the hardware manuals.)  This leads to a
situation where on a shadow fault, the guest walk succeeds but the
shadow walk fails.  The code assumes this can only happen when the
domain is dying, and makes an ASSERT() to that effect.  So currently,
in debug mode, this will cause the host to crash; in non-debug mode,
this will cause a page-fault loop.

This patch solves the problem by calling update_cr3() in that path
when the guest is in PAE mode, and only ASSERT()ing when the guest is
not in PAE mode.  The guest will get one spurious page fault, but
subsequent accesses will succeed.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 705fc47eee00367500ac3106a7a81df1d122648f..ccac23a0381e42ba41b327489861a9261c43d0ae 100644 (file)
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3201,7 +3201,16 @@ static int sh_page_fault(struct vcpu *v,
          * are OK, this can only have been caused by a failed
          * shadow_set_l*e(), which will have crashed the guest.
          * Get out of the fault handler immediately. */
+        /* Windows 7 apparently relies on the hardware to do something
+         * it explicitly hasn't promised to do: load l3 values after
+         * the cr3 is loaded.
+         * In any case, in the PAE case, the ASSERT is not true; it can
+         * happen because of actions the guest is taking. */
+#if GUEST_PAGING_LEVELS == 3
+        v->arch.paging.mode->update_cr3(v, 0);
+#else
         ASSERT(d->is_shutting_down);
+#endif
         shadow_unlock(d);
         trace_shadow_gen(TRC_SHADOW_DOMF_DYING, va);
         return 0;